哈囉大家好我是橘白卯咪，歡迎進來看看。

在擔任開發人員時，想的是如何用技術與工具解決問題；當角色轉換成PM之後，發現更多時候是 「想法」 跟 「表達」 的差異。

問題暴風雨

當一陣「問題暴風雨」來臨，技術跟工具上或許有很多選擇，強大的開發團隊能即時對應，解決了大部分或全部的問題。但在「問題暴風雨」過後，當客戶或主管問你「究竟發生了什麼」、「為什麼選擇這麼做」，如果身為開發人員或PM的你卻還沒從混亂中理出頭緒，做出了一份流水帳或描述太多技術細節的報告，讓客戶或主管難以從報告中理解狀況。這樣一來，無論是對專案的信任程度下降，或是在會議中遭受劈頭大罵與質疑，都是不好的結局。此時常聽到團隊成員說:

妳知道有哪些工具，可以快速呈現剛剛老闆問的那個問題嗎?

我用的XX工具，可是老闆說這不是他想要看的。

報告車輪戰

每一次灰頭土臉的會議後，從開發人員的角度，都會直接思考「技術」跟「工具」的使用；在下次的會議，卻發現上次的問題是解決了(或部分解決了)，在下次卻又出現了新的問題，或老闆想知道新的視角。好不容易度過了「問題暴風雨」，卻開始了「報告車輪戰」。手邊排定的工作正在執行，還需額外騰出時間準備接二連三的問詢，加班時數直線上升，痛苦指數也是。

我每次被罵完都要去冷靜一下，才能回來繼續寫code。

都開會就飽了，哪有時間開發。

當開發時間被壓縮了，為了趕上交付時程，開發人員可能沒有足夠的時間確保功能品質，導致另一場「問題暴風雨」的來臨。

可以動就好了，來不及了。

怎麼會出現這麼多問題，啊我是有時間測?

專案水晶球

專案運作過程，可能順水順風、晴空萬里，或者遭遇暴風雨。為了避免下一次的報告車輪戰，面對客戶或老闆的質問，身為PM或沒有PM的開發人員，都希望自己能像是有一顆水晶球，無論什麼問題，無論問過去、現在或未來，都能快速明瞭地給出答案。然而，身為不會魔法的麻瓜，現實上的我們為準備資料傷透腦筋。若辛苦準備的報告無法讓客戶或主管滿意，心情也會大受影響，甚至影響到工作效率。

理出頭緒

到頭來，如果我們能無論專案晴雨，盡可能的把事情好好理清楚，或許能減少一點暴風雨或車輪戰帶來的痛苦。沒有水晶球，那就自己打造一個吧!

從每一次的風雨中，漸漸找到了解決問題的方式。想藉由這個系列，把一路上使用過的方法跟步驟整理出來。

如果你也正在經歷 「問題暴風雨」 與 「報告車輪戰」 的路上，想成為全方位的 專案水晶球，無論你是專案中的PM、開發人員或任何角色都好，希望這個系列整理出來的方法，可以幫上你的忙。

這個系列有什麼好料

我把掌握專案狀況、表達專案訴求的方式，分成「三個步驟」--洽、chart、恰，步驟的詳細內容將在接下來的29天說明:

• 第一步驟：洽--問與答的之前與之間，找出關鍵

你到底有沒有聽懂我的問題？是要我講幾次？

你到底有沒有搞清楚狀況？

這到底有沒有用啊，用這方法好嗎？

「問題暴風雨」的過程，焦點或許在快速解決問題的方法，埋頭苦幹之餘需要抬起頭來，回想一下問題的真實原因；經歷「問題暴風雨」之後，要先釐清狀況。事實或許發生了，就是「那樣」。但要細說從頭時，如何將這一路上的英勇事蹟、重大轉變、前因後果、防範未然講清楚，在「報告車輪戰」之前，要先想好「說故事的方式」，預想聽者可能的擔憂。而有時平舖直述的講故事或許不夠引人入勝，要想好「爆點」跟「賣點」，避免讓聽者「無聊」，也能讓聽者覺得「獲得了新的發現」；在報告過程中，藉由聽者的反應，可以找出「為事情加分」的機會。

• 第二步驟：chart--話要說的讓人懂，畫也是

你這圖到底在畫什麼?

你想(藉由這個圖)表示什麼?要讓我知道什麼?

圖表是輔助說明的工具，但錯誤的運用圖表可能讓聽者誤解。讓我們來看看如何用圖把事情更清楚的表達。

• 第三步驟：恰

這樣寫老闆絕對會生氣!

這樣的報告法，A老闆可以，但B老闆不接受

面對不同的聽眾，有不同的表達方法。對於不同的目的，無論是喬時程、談需求或報告現狀，都有適用的講法與情境。運用這個步驟，讓事情「恰恰好」。

說明以上三個步驟的過程中，會以實際可能發生的案例來試著解決看看。

看到這裡，如果你覺得還蠻有趣，邀請你藉著這個系列，一起思考與學習。